COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This file lists changes to the METAFONT manual, occurring since its publication
C00041 00003	Experimental features in local METAFONTs
C00044 ENDMK
C⊗;
This file lists changes to the METAFONT manual, occurring since its publication
as a Stanford report in 1979 (which is the same as the version published by
Digital Press in December 1979). The programs and font specifications in
Appendix E have been thoroughly revised, and report CS780 ("The Computer Modern
Family of Typefaces") shows a more up-to-date version; however, some
significant changes to that appendix are listed below, and the real truth
appears in the computer files described in FILES.INF[FNT,DEK].

Page 4, line 8, TEX should have been told not to break at that hyphen!

Page 24, line 6, change "$h↓0$ units high," to "$l↓0$ units high, where $l↓0$ is
the current value of lpenht,"

Page 24, line 12, change it to "lpenht 25; rpenht 25;"

Page 28, table, change $h↓0$ to $l↓0$ in the lpen column and to $r↓0$ in the
rpen column

Page 34, line -22, change "tfxmode" to "tfmmode"

Page 34, lines -17 and -20, and page 35, lines -1 and -6, change "points" to
"pts" (total of five changes)

Page 38, line 17, change "DRAGON.TFX" to "DRAGON.TFM"

Page 48, table, change $h↓0$ to $l↓0,r↓0$ in the lpen,rpen column

Page 53, line 8, change (x+1,y) to (x,y+1)

Page 61, insert a new "dangerous bend" just before Chapter 9:
METAFONT has a limited memory available for storing subroutines. If you know
that some subroutine, say "s", is no longer going to be needed, you can remove
it from METAFONT's memory by writing "subroutine s:.".

Page 61, fifth line of Chapter 9, change "points" to "point" and "signs" to "sign"

Page 65, after line 14, insert:
{\bf charwx} and {\bf charwy} are used in an analogous way to specify the x and y
coordinates of the two-dimensional width vector of a character that might
be rotated.  These parameters are used when preparing fonts and font
information files for the Press world as described in Appendix P.  

Page 65, before line -11, insert new real parameters:
{\bf designsize} specifies the nominal body height of the font in units of
printers' points:  a "10 point font" is a font whose designsize is 10.
This parameter is used in constructing both the TEX and Press font
information files.

{\bf hresolution} and {\bf vresolution} specify the resolutions of the raster
in the x and y directions respectively.  This information is stored in the font
file intended for use by a Dover Press printer (ocmode).  These resolutions
should be given in pixels per point.

{\bf magnification} (normally 1.0) is a pure number that tells METAFONT the
amount by which the current font is being photographically expanded.  If the
magnification is not unity, it affects the interpretation of the designsize
and resolution parameters as explained in Appendix M.

{\bf rotation} (normally 0) specifies the {\sl rotation} attribute for use by the
Press world, in units of degrees. (See Appendix P.)

Page 65, lines -9 and -8, change to:
{\bf hpenht}, {\bf vpenwd}, {\bf lpenht}, and {\bf rpenht} (normally 1) are used
to specify the height of each hpen, the width of each vpen, the height of
each lpen, and the height of each rpen. It is best...

Page 66, after line 3, insert new integer parameter:
{\bf fontfacebyte} specifies the encoded value of the {\sl face} attribute for use
by the Press world (Appendix P).  This value must be an integer between 0 and 255
inclusive.  It is stored in TEX's font information file as well as in the
Press-oriented output files.  The default value is 0.

Page 66, lines 10 and 11, delete "; this information ... XGP".

Page 66, lines 14-19, change to:
crsbreak specifies a $y$ coordinate at which a tall character will be
broken into pieces when preparing it for an Alphatype CRS font. If you specify
several different crsbreaks for the same character, it will be broken into
several different pieces. At most 1020 nonzero rows of the raster should appear
between breaks. Furthermore, a crsbreak of 1000000 is used to indicate a character
that is combined with others for special typesetting effects (e.g., parts of a
varchar); this causes the Alphatype software to take special care to position
the character perfectly.

Page 66, before line -8, insert new title parameters:
$\bullet$ <title parameter name> "<any desired title>"

Some parameters have titles as values instead of numbers. Such parameters,
like titles themselves, may not appear in subroutines. Lower case letters in
title parameters are converted to upper case letters so that other programs
that must deal with such parameters do not need to make case distinctions.
The following title parameters are understood by METAFONT:

{\bf codingscheme}  describes the correspondence between character codes and
character shapes used by the current font. For example,
	codingscheme "ASCII"
describes an ascii character set. This descriptive string is put
into the font information file for TEX. At the moment it is used only
in some auxiliary software that reads and writes .TFM files; but since it provides
important documentation, wise users will specify the coding scheme explicitly
by means of this title parameter.

{\bf fontidentifier}  specifies the {\sl family name} attribute for use by the
Press world (see Appendix P). This family name is stored in TEX's font information
file as well as in the Press-oriented output files.  

Page 66, line -4, change "and {\bf penreset}" to "{\bf penreset}, and {\bf points}"

Page 67, lines 8-10, change "from ... to ..." to "between ... and ..., inclusive"

Page 67, line -12 (re penreset), change "begins." to "begins or a section ends."

Page 67, before line -11, insert:
{\bf points}	causes METAFONT to display labeled points in proof mode.
{\bf arrow}	causes METAFONT to mark the reference point of proofmode output so
	that the figure can be merged with other documents (allowed only when
	proofmode output goes to Press files).
{\bf color}	causes METAFONT to prompt the user for what colors to use in
		proofmode output (allowed only when such output goes to Press files).

Page 67, line -9, change "These" to "If points is turned on, these"

Page 67, lines -6 thru -4, delete "Thus you ... section."

Page 68, after line 2, insert new output mode:
{\bf ocmode} causes METAFONT to output a file of font images in the format required
for Dovers and some other Press printers.

Page 68, line 11, change "tfxmode" to "tfmmode".

Page 68, after line 12, insert new output mode:
{\bf dotwdmode} causes METAFONT to output a file of width information that programs
in the Press world need when they use a font.  (This mode can't be called 
"{\bf wdmode}" because that word starts with a "w".)

Page 68, line 17, change "tfxmode" to "tfmmode".

Page 69, line 11, change ".XGP, .CHR, .TFX" to ".XGP or .DVI or .PRESS,
.CHR, .TFM, .OC, .WD"

Page 69, line 12, change "tfxmode" to "tfmmode, ocmode, dotwdmode".

Page 71, line 22, change "range." to "range (<coordinates>)."

Page 73, replace last four lines by:
! Ligature/kern program didn't end.
The final entry of your final <lig instruction list> ended with a comma.
Proceed; the comma will be ignored.

Page 74, a new error message:
! lpen height too small, set to 1.
You shouldn't try to make lpenht less than 0.5. Proceed, and it will be set to 1.

[A similar message about rpenht goes on page 77, and the wording of the similar
messages for hpenht and vpenwd should be shortened to match.]

Page 74, new types of overflow:
brksize,	number of crsbreak points in a character;
initblocks,	number of preamble blocks in binary font file

Page 77, a new error message:
! Square root of -<constant>, replaced by 0.
You tried to take the square root of this negative number. Proceed, and its
value will be zero.

Page 77, a new error message:
! Title expected, command flushed.
A title parameter to METAFONT should begin with a double-quote mark. Proceed,
and all tokens up to the next semicolon or period will be ignored.

Page 79, new error messages:
! Varchar can't be in the middle of a charlist.
A character code specified as a varchar is allowed in a charlist only at the end.
Proceed; if the message says `command flushed', the remainder of
this charlist is ignored, otherwise the varchar specification for the current
character code is ignored.

! Varchar can't have ligature/kern.
A character code specified as a varchar must not appear as a label in a <lig
instruction list>. Proceed; if the error message says `command flushed', the
remainder of this <lig instruction list> will be ignored, otherwise the varchar
specification for the current character code is ignored.

Page 82, after line -3, insert:
fontidentifier "CMR"; ptsize=10;

Page 83, line 14, change "eight" to "nine"  

Page 83, after line 15, insert new "p" variable:
ptsize is the nominal font body height, 10 points in our example.

Page 84, line 5, interchange "height" and "width"

Page 85, line 14, change 37/23 to 23/37

Page 86, line -4, delete the "and" after the semicolon

Page 86, line -2, change "drawn." to the following:
drawn;  and mode 3 generates a font for a Dover Press printer with a
resolution of 384 pixels per inch, displaying nothing.

Page 87, bottom line, "c ↔ px" should be "m ↔ px"

Page 88, lines 2-3, change "Fortunately ... x-height." to:
Variable  m  is used to stand for the x-height, since a line at this height is
traditionally called the "mean line."

Page 88, line 6, a "c" is in row c →→ an "m" is in row m
(and so on, changing c to m in lines 7 and 8)

Page 88, line 7, change "pixel ... appears" to "pixels ... appear"

Page 88, lines -9 through -5:
w8, the curve height;
w9, the upper-case stem height.
Note that the last four of these variables have no "p-variable" equivalent; they
satisfy the approximate relation
w6/w0 \approx w7/w1 \approx w8/w2 \approx w9/w4 \approx aspect.
The hpenht, lpenht, and rpenht are $w↓6$ and...

Page 90, lines 16-19 of Figure E-2 should be indented

Page 91, lines 12 and 16 of Fig. E-3, change "counter" to "bowl"

Page 91, line -11, a "W" too. →→ "M" and "W".

Page 91, replace the last five lines by:
designsize ptsize;
proof=0; lowres=1; crs=2; dover=3;
mag=1.0; magnification mag;
if mode=proof: proofmode; drawdisplay; pixels=36mag; blacker=0;
else:	if mode=lowres: fntmode; tfmmode; chardisplay; pixels=3.6mag; blacker=1.2;
	else:	if mode=crs: crsmode; tfmmode; titletrace; pixels=73.7973mag; blacker=1;
		else:	if mode=dover: ocmode; tfmmode; dotwdmode;
				pixels=384*.013837*mag; blacker=0.75;
			else:	input mode; % get mode information from another file
			fi;
		fi;
	fi;
fi;
hresolution pixels; vresolution pixels;

Page 92, line 3, change comment to read:
% the vertical size of the font, normally equal to ptsize

Page 92, lines 5 and 17, change c to m

Page 92, lines 12-15, change to:
w6=round(pixels.pw.aspect+blacker);
w7=round(pixels.pwi.aspect+blacker);
w8=round(pixels.pwii.aspect+blacker);
w9=round(pixels.pwiv.aspect+blacker);
hpenht w6; vpenwd w0; lpenht w6; rpenht w6;

Page 92, line 23, change "3pu,3pu" to "3pu,2pu"

Page 92, line -2, delete "charic italcorr", also delete line -1

Page 93, lines 1-8, change to:
tu=pu.pixels; uw=charuw-sc.(lftcorr+rtcorr);
if fixwidth=0: moduw=uw;
else: moduw=9; new italcorr; italcorr=0;
fi;
r=charuw.u=round((moduw.tu-2).charuw/uw);
charic italcorr; charwd moduw.pu; chardw moduw.tu;
incx round(-sc.lftcorr.u);
if mode=proof: call box(round sc.lftcorr.u);

Page 93, line 10, "guidelines"

Page 93, line 19 should be "y5 = y6 = m; draw 5..6; % mean line (x-height)"

Page 96, change "ru" to "pu" in 8 places

Page 96, line -8, change "`ff" to "``ff".

Page 96, line -13, change "example" to "particular example"

Page 96, line -15, change "tfxmode" to "tfmmode"

Page 99, lines 1-4, change the sentence to read as follows:
If this is not zero, it denotes the amount of space in points whose multiples
will be used for all spacing in math formulas: the otherwise-specified
conventions for thin space, thick space, \mskip, etc., will be changed so that
there is no streching or shrinking, and the amount of space will be increased in
magnitude if necessary to make it a multiple of the math space.

Page 100, line -11, delete "in lieu of a charic command"

Page 100, lines -6 through -8, change the sentences to read as follows:
For example, the extensible left parenthesis symbol in font cmathx has been
defined by "varchar '060, 0, '100, '102";  the second expression is zero
because a parenthesis doesn't have a middle component.  (The code c itself may
appear as one of the four components of the varchar command for c, but
this is not required.)

Page 100, line -1, delete ", 0" at the end of the display.

Page 101, lines 3-11, change to read as follows:
... '060 (the end of the list).  Suppose that TEX does reach '060.  As we
noted above, the code '060 in cmathx represents a built-up character.  Thus,
TEX can use the pieces specified in that varchar command to construct a
left parenthesis of the appropriate size.  If the last character in a
charlist isn't a varchar, then TEX will use it whether or not it is large
enough.  For example, the slash symbols in cmathx are specified by "charlist 
'016, '036, '054" where character '054 is not a {\bf varchar}, but is simply
the largest slash present.  A charlist in general consists of <expression>s
(usually constants) that should round to character codes between 0 and 127.
The last character in a charlist may be a {\bf varchar}, but all of the other
characters in the list must be non-{\bf varchar}s.  In addition, none of the
characters in a {\bf charlist} should have a ligature/kern program, since TEX ...

(NOTE INCOMPATIBLE CHANGE reflected in the last paragraph: charlists don't
end with 0 any more unless character 0 is the last in the list.)

Between pages 101 and 102, insert two new Appendices:
Appendix M:  Producing magnified fonts

The fonts that METAFONT produces are intended for use by raster printers.
In many cases, the paper or film that comes out of the raster printer is the
final product.  In other situations, however, the output of the printer is
subjected to further processing, perhaps including a photographic scaling.
For example, the papers in many conference proceedings are photographically
reduced by 25% from the manuscripts that the authors submitted.  In such a
situation, the output of the raster printer should be thought of as only a
middle stage of the printing process.  The font images used by the raster
printer should be magnified by $33{1\over3}$% so that the final result after
photographic reduction will be the correct size. The presence of such
photographic reduction in the printing process effectively increases the
resolution of the raster printing device, at the price of reducing the
effective size of the piece of paper that the raster printer can handle.

Some font families have the characteristic that different sizes of the same
face are merely obtained by a photographic scaling, or as close to a
photographic scaling as the discrete nature of the underlying raster will
permit.  If we want to submit a paper to a conference and we are using fonts
from families of this type, we need only scale up the point sizes that we
request.  But, as noted in Appendix E, the Computer Modern fonts do
not scale photographically:  the height, width, stroke widths, and serif
dimensions change at different rates to improve the appearance of large and
small letters.  Thus, if we are using Computer Modern fonts, we really want
to print fonts that are photographically magnified, not just switch to fonts
that were designed to be larger.  METAFONT has some built-in mechanisms to
assist in the creation of such magnified fonts.

Some of the consumers of METAFONT's output files are smart enough to
understand about magnified fonts.  For example, both the TEX and Press font
information files are written in a scalable format:  the metrics in them can
be scaled to allow for any photographic magnification of the basic font.
This means that only one metric information file is needed per font, even if
several different magnifications of that font are in use.

But other consumers of METAFONT's output files don't understand about
magnified fonts:  most raster printers fall in this class.  When producing
output files for such ignorant consumers, METAFONT itself must scale all
distances by the magnification when producing the output file.

The output code in METAFONT is able to produce correct output files for both
smart and ignorant consumers.  But in order to avoid getting METAFONT
confused, the user of METAFONT must ask for magnified fonts in the correct
way.  To understand the issues involved, think about the structure of a
typical METAFONT program.  We can divide most of the variables in the program
into two classes:  there are {\sl point} variables, which measure ideal
distances, independent of raster resolution;  and there are {\sl pixel}
variables, which measure distances on the discrete raster.  The pixel
variables are determined by careful rounding of expressions involving
point variables.  

In order to construct a magnified font, the METAFONT program must be altered
so that the values of all of the pixel variables are scaled by the
magnification factor (except for the effects of rounding).  That has to
happen in order to draw magnified characters.  But it isn't so clear whether
or not the values of the point variables should also be scaled.   And it
makes a difference whether the point variables are scaled or not, since
font metrics such as {\bf designsize} and character metrics such as
{\bf charwd} are given in terms of point variables.  The METAFONT convention
is that {\sl point variables should not be scaled when producing a magnified
font}.  After all, the point variables describe ideal distances;  they should
be talking about the final result of the entire printing process, not the
temporary magnified output of the raster printer.

In order to produce a magnified font with METAFONT, it is enough to do the
following:  (i) scale all pixel variables, except for the effects of
rounding;  (ii) don't scale any point variables, or any font or character
metrics;  (iii) tell METAFONT what the magnification is by setting the
parameter {\bf magnification} to the appropriate real number.  Note that
some variables have more complex units.  You can determine whether or not
to scale these variables by combining rules (i) and (ii).  For example,
a resolution variable has "pixels per point" as its units;  since pixels
should be scaled and points shouldn't, a resolution should be scaled.  In
particular, the parameters {\bf hresolution} and {\bf vresolution} should
be scaled.

As an example of font magnification in action, the beginning of file
cmbase.mf in Appendix E shows all that is requied. For example, to get a
$33{1\over3$ magnified cmr10 font for a Dover Press printer, one may type
	mode=dover; mag=1.33333333; input cmr10.
When the file cmbase.mf is eventually input, METAFONT will stop with the
`Inconsistent equation' error when it reads the statement `mag=1.0', but you can
simply ignore the error and hit <carriage-return>. Everything else will work fine.

Another way to incorporate magnification into the program of Appendix E,
would be to use, e.g., mode $-dover$ for dover mode with special magnification.
The statement `mag=1.0' could be replaced by
	if mode<0: new mmode; mmode=-mode; new mode; mode=mmode;
	else: mag=1;
	fi;
now there will be no `Inconsistent equation' error message.

Note that the magnification parameter only has to appear explicitly in two
places:  in the statement that defines the basic resolution variable named
"pixels", and in the statement that sets the parameter
{\bf magnification}.  All of the pixel variables in the Computer Modern
programs will be correctly scaled without any other modifications, since
they are determined by rounding an expression involving "pixels" as a
factor. 


Appendix P:  Font information for Press

There is a body of printing software developed within the Xerox Corporation
that is centered around a print file format called Press.  METAFONT can be
used to produce fonts for use with Press software and hardware.  The Press
world has its own conventions about fonts and font information, different
from those of the TEX world.  These differences and comments on how to resolve them
are discussed in the present appendix, which may be regarded as typical of
the types of appendices needed to interface METAFONT with other conventions
that already exist in industry.

The first difficulty arises in the choice of raster coordinates.
METAFONT believes that the origin point of a character, the (0,0) point
of the METAFONT raster, is located in the center of a pixel.  The Press
font world, on the other hand, makes the convention that the origin of a
character is located slightly below and left of the center, at the point where
four pixels touch, namely at point (-0.5,-0.5) in METAFONT's coordinate system.
In other words, if METAFONT's pixel (0,0) is blackened, the lower left corner of
this pixel will be at point (0,0) in the Press-oriented editing software.
But no change is necessary to the METAFONT programs that create the characters.

Press also has a different view about character metrics.  In the Press
world, characters don't have a height and depth, only a width.  But this
width is not a single number:  instead, the width of a character is a
two-dimensional vector.  The end of the width vector determines the position
on the plane where the origin of the next character should be located, if
two characters are adjacent in a string.  The use of two-dimensional width
vectors allows for fonts that have been rotated by some angle other than a
multiple of 90 degrees, as well as for languages that don't go left to right.

METAFONT determines the width vector of a character for Press output modes
in one of two ways, as determined by the setting of the "control bit"
called {\bf vectorwidths}.  The default condition is that {\bf vectorwidths}
is not set.  In this case, the value specified as the TEX {\bf charwd} is
used for the x component of the width vector, and the y component is set to
zero.  This means that Press will agree with TEX about the widths of
characters.  If {\bf vectorwidths} is set, however, METAFONT will use the
values of {\bf charwx} and {\bf charwy} as the x and y components, allowing
the user to specify an arbitrary width vector.

The final major difference between the TEX and Press font worlds revolves
around the issue of naming a font.  In the TEX world, every font has a text
name.  Each font is stored in a separate file, and the font's text name,
supplemented by a standard extension, is used to name that file.  Files that
contain metric information for a font use the same text name with a different
extension.  In the Press world, fonts are gathered together into large files
called  dictionaries.  At the beginning of a dictionary is an index that
describes what fonts the dictionary contains, together with a description of what
kinds of information are present.  A font is specified by giving the values of four
attributes:  the {\sl family name}, {\sl face}, {\sl size}, and
{\sl rotation}.

In order for METAFONT to produce fonts for the Press world, it must be told
the appropriate values of these attributes.  METAFONT decides upon a
{\sl family name} by using the value of the title parameter
{\bf fontidentifier};  the {\sl face} is specified by the integer parameter
{\bf fontfacebyte};  and the {\sl rotation} is derived from the real
parameter {\bf rotation}.  The standard file of character width information
in the Press world contains metrics that can be scaled to cover any size.
For raster fonts, the {\sl size} attribute is determined by taking the
distance specified as the {\bf designsize}, and multiplying by the pure
number specified as the {\bf magnification}.

Page 102l, new entry "Baseline, 7--8".

Page 102r, first page for crsbreak should be 66, not 67

Page 102r, new index entries:
$l↓0$, 24, 28, 48.
{\bf lpenht}, 24, 65, 74, 88.

Page 103l, add p. 72 under "hpenht".

Page 104l, new index entries:
$r↓0$, 28, 48.
{\bf rpenht}, 24, 65, 77, 88.

Page 104r, new index entry: {\bf subroutine}, 55.

Page 104r, change "tfxmode" to "tfmmode"

Page 104r, add p. 80 under "vpenwd".

Page 105, new entry "%, 35."
Experimental features in local METAFONTs

Lyle Ramshaw at PARC is experimenting with splines that control curvature
as well as tangents at the key points; watch this space for news about
the syntax and semantics of this extension.

Primitive input of binary files is being implemented temporarily with a "binput"
statement. To use this feature, prepare one or more binary files containing the
following: One or more entries of length 2+mn consisting of
		m	(1 word)
		n	(1 word)
	(36-bit data)	(mn words),
followed by an entry with m≤0 to denote end of file. The 36-bit data words
specify the bits of a character in m rows, with the first row corresponding
to y=0, the next to y=-1, etc.; within a row there are n words specifying
36n bits from left to right, corresponding to x=0 to x=36n-1.
The settings of incx and incy will be added to move the raster image;
for example, if incx=-18 and incy=15, the first of the mn words specifies
the 36 bits for y=15 and -18≤x<18. The 36mn bits are or'ed in to whatever
is already in the raster. (Only incx and incy are used, not trxx etc.)
The METAFONT statement "binput" now means this:
If no file for binary input is open, the user will be prompted to supply
a file name. Otherwise the next entry from the open file will be used, until
the end of file, when the user will be prompted for another file name.

Warning: "binput" will not be supported in later versions of METAFONT, it
will be supplanted by a more compact and machine-independent run-length-encoded
format for characters.